The present invention is related to software programming techniques. In many source-level programming languages, discrete portions of a software program are written as routines or functions that each return one or more return values. Software-program functions are somewhat related to the concept of a “function” in mathematics, mapping one or more input values, or domain variables, to one or more return variables. Often, various error conditions, or special conditions that cannot be easily handled, arise during execution of a function. It is a common software programming technique to export the fact that an error condition or other anomaly has arisen by returning a special return value, or distinguished value, to a calling routine. For example, many standard C-language and C++-language routines return pointers, essentially memory addresses, to various data and objects, and, in the case of the occurrence of an error condition, return a special value “NULL,” often encoded as the integer value “0,” that can never be the value of a valid pointer. In such cases, the return value must be checked by the calling routine for being equal to NULL prior to its use. In the case of a NULL pointer, for example, an attempt to dereference the pointer causes a fault condition at the machine-instruction level, since the virtual-memory address “0” is generally not accessible to source-level routines. The fault condition generally results in termination of the routine, and, in certain cases, may result in more serious conditions, such as operating-system crashes, data corruption, and other undesirable phenomena.
Failure to check a return value for NULL, or another distinguished value indicating an error condition, is a common programming error. When this programming error occurs in an application program directly following return of the function or routine that returns an error condition encoded in a distinguished value, an annoying, but easily debugged, application-program halt may occur. More serious problems, however, may occur in operating-system programs, or in any program in which the unchecked return value is not immediately used, but, instead, passed on to other routines or statements that may reside many instructions away from the function call. In operating systems, a premature program halt may not be easily debugged, because the halt may bring the entire computer system to a halt, without preserving the data needed to determine where, in the operating system code, the halt occurred. When unchecked return values are passed through various additional routines and statements, it may be quite difficult to backtrack through hundreds, thousands, or tens of thousands of machine instructions or source-level statements to identify the point where the return value was not checked. Additionally, it often occurs that a return value is initially checked at one pointer after return of a routine, but later, the return is inadvertently accessed inappropriately despite the initial check. Such errors can be especially difficult to track down, because it appears that the return value was properly handled. Finally, many commonly used routines almost never return an error value, but are used many times throughout a large program. Memory allocation routines, such as malloc in C programming environments, represent one example of often called, but seldom failing routines. For such routines, return value checking can represent significant instruction execution overhead that is almost never necessary. Software programmers, computer designers and manufacturers, and, especially, operating system developers have therefore recognized a need for early detection and trapping of failure-to-check-a-return-value errors in programs, detection and trapping of errors resulting in use or access of a return value in a particular way, despite an initial check that indicated that the return value should not be used or accessed in that way, and a need for avoiding unnecessary error checking of return values.